1. Field of the Invention
The present invention relates to methods and systems for testing network communications devices, systems and applications.
2. Description of Related Art
Testing high capacity, IP-based intelligent networks requires the origination of Internet-scale volumes of simulated user traffic in laboratory environments. The current generation of high-speed network performance testing equipment is generally based on either:
Proprietary hardware-based “packet blasters” that use pre-configuring quasi-static packets at or near “wirespeed;” or
TCP socket-based software that runs on large numbers of general purpose (or slightly modified) computing platforms.
As the density, speed and intelligent traffic management capabilities of network devices increase, traditional high-volume traffic generation solutions are less able to simulate real-world scenarios.
Traditional network routing and switching devices are stateless in that these devices make decisions based on information that is contained within these headers without maintaining any information about previous packets. They do not maintain any type of connection to the client or server at either end of the TCP transaction.
In order to test a stateless device, simulated traffic only needs to look like “real” traffic on a packet-by-packet basis. There does not need to be a complex relationship between the packets, so the transmitting device does not need to maintain any state or have any dynamic behaviors. For this reason, the current generation of high performance traffic generators do not require a full TCP/IP stack for performance testing. Specialized hardware is used to generate wirespeed packets that are varied algorithmically by overlaying variable length incrementing or random patterns over a “base packet” without any consideration of received packets. These conventional stateless test devices are commonly referred to as packet blasters.
True TCP sessions contain a feedback mechanism. For example, a TCP receiver sends acknowledgement packets to a TCP sender that advertise a window size to the TCP sender that inform the TCP sender the size of the receiver's receive buffer. The sender uses the advertised window size to control the flow of packets sent to the receiver. This mechanism causes the flow of incoming traffic to vary as a function of receiver performance. For instance, as a TCP receiver becomes overloaded, the rate of removing and processing packets from its TCP receive buffer decreases. As a result, the window size advertised to the sender decreases, and the TCP sender slows the flow of packets sent to the receiver. In addition, the mechanism can generate redundant data. For example, if a TCP receiver receives an out-of-sequence packet, the receiver will send a duplicate acknowledgement to the sender indicating that an out of sequence packet was received. Because this feedback mechanism exists on every TCP connection, overall TCP session throughput becomes the dominant performance metric.
Unlike traditional switches and routers, server load-balancing (SLB) devices may maintain state. Server load-balancing devices are also referred to as content switches. In the most basic implementations, this takes the form of “persistent sessions” where all packets from a specific user (source IP address) are routed to the same server (destination IP address). In order to accomplish this, the SLB may maintain a table of established client/server connections and look up the server to which a packet should be routed based on the client address. Other examples of stateful network devices include firewalls, VPN gateways, traffic shapers, spam filters and virus-scanning gateways.
The next generation of SLB devices is much more sophisticated. They may make routing decisions based on a combination of data from the IP, TCP and HTTP header (URL, Cookie) and may even actively participate in a client/server session by proxying and aggregating multiple client connections into a pool of pre-existing server connections. Since the SLB may have a full TCP/IP stack, it becomes much more difficult to test the device with stateless, algorithmically generated traffic. The performance of the SLB is sensitive to many more characteristics of the TCP session.
Typical switches and routers only process Ethernet and IP headers, respectively. Traditional server load balancers process the IP source and destination address fields and TCP source and destination port fields. Next generation server load balancers process every header from the Ethernet header through application-level headers. Furthermore, some switches and routers also do “deep packet inspection,” looking past even the application-level headers. As a result, these next generation devices cannot be tested using traditional stateless packet blasters.
Today's load balancing switches generally handle tens of thousands of session establishments per second with fewer than 100,000 concurrent sessions established. Moore's Law is adhered to not only in general purpose computing platforms but in network devices as well: the new generation of load balancers will handle hundreds of thousands of sessions per second with 1,000,000 or more concurrent sessions established.
While stateless hardware-based solutions cost a fraction as much as fully stateful software-based solutions for high packet rates, stateless solutions do not provide realistic enough traffic to accurately measure the performance of stateful network communications devices, such as new generation SLBs. In fact, SLB devices that proxy connections with nearly a full TCP stack will drop simulated connections attempted by such a device. At the other extreme, software-based full stack implementations are prohibitively expensive to acquire and difficult to maintain and operate for high rates and/or volumes of connections. For example, software-based full TCP stack implementations may require multiple machines with multiple processors and network interfaces to achieve the number of TCP sessions required to test a stateful network communications device, such as a server load balancer. Similarly, TCP-based application performance cannot be determined/inferred by generating stateless traffic and measuring network layer performance metrics.